An async iterator returns Promises from next(), following the Async Iterator Protocol with Symbol.asyncIterator. Values are resolved asynchronously.
Regular iterators return { value, done } directly. Async iterators return a Promise that resolves to { value, done }, allowing iteration over asynchronous data sources (e.g., streams, paginated APIs). They are consumed with for await...of loops.
We have a function that returns an array of user IDs. How would you loop over it with a regular iterator, and what would you need to change to handle a stream of IDs that arrives asynchronously?
If you write for await (const x of someIterable) on an object that only implements Symbol.iterator, what runtime error do you see and why?
Show me a small Node.js snippet that reads a file line‑by‑line using an async iterator so the whole file isn’t loaded into memory.
Our service fetches paginated data from an external API returning a promise per page. We tried a for...of loop and got unexpected behavior. Walk me through why that happened and how you’d fix it with async iteration.
During a code review a teammate swapped a sync iterator for an async one but forgot to implement Symbol.asyncIterator. The code compiled but failed at runtime. How would you detect and debug this issue?
We have a utility that accepts any iterable and returns an array of its values. How would you extend it to also support async iterables without breaking existing callers?
Our data pipeline processes millions of records from a message queue using a sync iterator over a buffered array, causing back‑pressure problems. Design a solution using async iterators to provide proper flow control and discuss trade‑offs.
We need to stream large JSON results to clients over HTTP/2. Explain how you’d implement the server‑side using async iterators, and what you must consider for cancellation and error propagation.
A legacy module uses custom iterator objects exposing a next() method but not Symbol.iterator. We want to migrate to async iteration across the codebase. Outline a migration strategy that minimizes risk and keeps compatibility.
Our organization is standardizing on async iteration for all I/O streams. What architectural guidelines would you set for libraries, testing, and documentation to ensure consistent use of the async iterator protocol across multiple teams?
We have a monorepo with both React front‑ends and Node.js services. Some shared utilities need to work in both sync and async contexts. How would you design an abstraction that can be consumed as either a regular iterator or an async iterator, and what impact does that have on type definitions and build pipelines?
Considering possible future changes to the async iterator protocol, how would you future‑proof our codebase to handle protocol extensions without breaking existing consumers?